哈囉大家好，歡迎來到 Istio 的第四天！

在昨天的文章中，我們為服務之間的通訊啟用了 mTLS 雙向認證。這解決了認證 (Authentication) 的問題，確保了每一次通訊的雙方，都知道對方是「誰」。

但一個更重要的安全問題隨之而來：知道了「你是誰」之後，我該如何決定「你能做什麼」？

• ota-frontend 服務，是否有權限刪除用戶資料？
• cms-service，是否應該被允許存取 ota-backend 的核心 API？

今天，我們就要來學習 Istio 的授權 (Authorization) 機制 AuthorizationPolicy。

Part 1：AuthorizationPolicy 的核心思想：預設放行，一旦啟用則預設拒絕

在深入語法之前，我們必須先理解 AuthorizationPolicy 的一個核心運作模式，也是容易混淆的地方：

1. 預設行為 (Default Behavior)：
   • 如果一個工作負載（例如 ota-backend 的 Pods）沒有任何 AuthorizationPolicy 套用在它身上，那麼 Istio 的預設行為是 「允許所有流量 (ALLOW ALL)」。
2. 啟用後的行為 (Once Enabled)：
   • 一旦為該工作負載，套用了第一條 action: ALLOW 的 AuthorizationPolicy，它的行為模式就會立刻翻轉為 「預設拒絕所有 (DENY ALL)」。
   • 從此刻起，只有明確符合 ALLOW 規則的流量，才會被放行。所有不符合規則的流量，都會被 Sidecar Proxy 以 403 Forbidden 的錯誤直接拒絕。

這個「一旦設定白名單，就自動啟用黑名單」的設計，是實現零信任網路安全模型的關鍵。

Part 2：解構 AuthorizationPolicy YAML

AuthorizationPolicy 讓我們可以用宣告式的方式，定義誰（from）可以在什麼條件下（when），對我們的服務執行什麼操作（to）。

官方文件是這樣定義的：

Istio Authorization Policy enables access control on workloads in the mesh.
(Istio 授權策略能夠對網格中的工作負載，進行存取控制。)

讓我們來解構一個 AuthorizationPolicy 的核心欄位：

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: backend-auth-policy
  namespace: project-space
spec:
  selector: # <-- 1. 這個門禁系統要裝在哪個辦公室門口？
    matchLabels:
      app: ota-backend
  action: ALLOW # <-- 2. 這是一份「允許」名單 (白名單)
  rules:
  - from: # <-- 3. 誰可以刷卡？(來源)
    - source:
        principals: ["cluster.local/ns/project-space/sa/ota-frontend-sa"]
  - to: # <-- 4. 他們可以進哪個房間、做什麼事？(操作)
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/v1/orders/*"]
  - when: # <-- 5. 需要滿足什麼額外條件？(可選)
    - key: request.headers[x-user-group]
      values: ["internal"]

1. selector：指定這條策略要套用在哪個（或哪些）工作負載上。這裡是裝在所有帶有 app: ota-backend 標籤的 Pods 門口。
2. action：可以是 ALLOW（白名單）或 DENY（黑名單）。DENY 規則的優先級高於 ALLOW。
3. rules.from.source：定義了誰是合法的請求來源。principals 是最重要的欄位，它會去檢查請求來源 mTLS 憑證中的身份（也就是它的 Service Account）。
4. rules.to.operation：定義了允許執行的操作。這是 AuthorizationPolicy 作為第七層防火牆最强大的地方，它可以檢查 methods (GET/POST), paths (/api/v1/*) 等 HTTP 的具體內容。
5. rules.when：可以加入更複雜的條件判斷，例如檢查請求的 Header 或 IP 位址。

Part 3：設定精細權限

讓我們來為 ota-backend 服務，設定一組更真實的存取規則：

• 規則一：只允許來自 ota-frontend 的請求，可以對 /api/orders 路徑執行 GET 和 POST。
• 規則二：只允許來自 admin-dashboard 服務的請求，可以執行任何操作。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: ota-backend-policy
  namespace: project-space
spec:
  selector:
    matchLabels:
      app: ota-backend
  action: ALLOW
  rules:
  # --- 規則一：給前端的權限 ---
  - from:
    - source:
        # 假設 ota-frontend 使用 ota-frontend-sa 這個 Service Account
        principals: ["cluster.local/ns/project-space/sa/ota-frontend-sa"]
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/orders*"]
  # --- 規則二：給管理後台的權限 ---
  - from:
    - source:
        principals: ["cluster.local/ns/project-space/sa/admin-dashboard-sa"]
    # 沒有 "to" 欄位，代表允許所有操作`

一旦這個策略被套用：

• ota-frontend 嘗試 DELETE /api/orders -> 將被拒絕。
• cms-service (使用不同的 Service Account) 嘗試 GET /api/orders -> 將被拒絕。
• admin-dashboard 嘗試 DELETE /api/orders -> 將被允許。

Part 4：AuthorizationPolicy 的決策流程

我們現在能控制流量、也能保護流量了。但下一個問題是：我們該如何看見這些在網格中穿梭的流量呢？當請求變慢或出錯時，我們該如何追蹤問題的根源？

在明天的文章中，我們就要來探索 Istio 的可觀測性 (Observability) 能力，並認識它的視覺化儀表板！明天見！